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SUPPORTING 

COMMUNITIES  OF  INTEREST 
IN  A  NET-CENTRIC 
INVESTMENT  ENVIRONMENT 


NOEL  DICKOVER 

In  the  Department  of  Defense  (DoD),  significant  effort  has  been  devoted 
to  conceptualizing  a  net-centric  environment,  particularly  with  respect  to 
network-centric  operations  and  warfare.  In  accordance,  the  DoD  Chief 
Information  Officer  has  issued  a  Net-Centric  Operations  and  Warfare 
Reference  Model  and  a  Net-Centric  Checklist.  In  addition,  the  Net-Cen¬ 
tric  Functional  Capabilities  Board  is  developing  a  draft  Net-Centric  En¬ 
vironment  Joint  Functional  Concept.  While  the  focus  of  the  aforemen¬ 
tioned  products  is  largely  oriented  to  the  warfighter,  DoD  senior  man¬ 
agement,  through  various  management  initiative  decisions,  has  em¬ 
braced  a  movement  toward  a  net-centric  environment  in  an  effort  to 
effect  net-centric  business  transformation  and  e-Government. 


In  support  of  various  Department  of  Defense  (DoD)  management  initiatives, 
the  information  technology  (IT)  Acquisition  Management  TransformationRapid 
Improvement  Team  (RIT)  Pilot  Project  has  provided  a  blueprint  for  how  the  over¬ 
all  investment  community  can  adapt  to  the  net-centric  environment  (DoD  CIO,  2004). 
After  a  three-year  period  of  research  and  experimentation,  the  RIT  Pilot  Report 
has  concluded  that  if  we  are  to  maintain  information  superiority  for  the  warfighter, 
the  investment  community  must  benefit  from  net-centricity  in  the  same  way  as  the 
warfighting  community.  The  thesis  of  the  RIT  Pilot  Report  is  that  the  Department’s 
functional  and  acquisition  business  communities  can  also  employ  net-centricity  to 
achieve  information  superiority  that  in  turn  can  yield  unprecedented  speed,  agility, 
and  self-organization  for  our  IT/National  Security  System  (NSS)  investment  process. 
This  idea  of  self-organization  is  analogous  to  self-synchronization  in  network-centric 
warfare  (NCW).  Self-synchronization  in  NCW  is  employed  to  allow  autonomous 
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groups,  each  operating  under  the  same  mission,  to  rapidly  adapt  to  changing  opera¬ 
tional  circumstances. 

The  development  of  a  net-centric  investment  environment  creates  an  environment  where 
a  transparency  in  business  operations  and  full  adherence  to  post-before-process  concepts 
generate  a  shared  situational  awareness  to  all  stakeholders,  both  in  terms  of  communicating 
current  warfighter  needs  and  in  providing  immediate  access  to  cost,  schedule,  and  perfor¬ 
mance  measures.  Oversight  and  governance  must  be  transformed  and  decentralized  to  allow 
flexible  operations.  Risk  management  must  become  institutionalized  and  integrated  into  an 
evolutionary  acquisition  framework  with  smaller,  more  targeted  development  increments. 
Policies  must  be  continually  reevaluated  to  ensure  that  rapid  and  flexible  responses  are  possible 
while  still  adhering  to  the  law.  Overall,  a  net-centric  investment  environment  is  best 
characterized  as  one  that  self-organizes  to  rapidly  meet  the  constantly  changing  needs 
of  the  warfighter. 


Risk  management  must  betome  institutionalized 
and  integrated  into  an  evolutionary  a<quisition 
framework  with  smaller,  more  targeted 
development  intrements. 


A  net-centric  environment  is  an  environment  in  which  there  is  immediate  access  in 
digital  format  to  the  information  needed  to  conduct  business.  Such  an  environment 
requires  digital  connectivity  and  collaboration  tools,  an  information-sharing  work  culture, 
and  the  ability  to  improve  overall  performance  by  disseminating  best  practices  and  lessons 
learned  to  the  rest  of  the  workforce.  As  is  clear  from  business  literature  (Megill,  2004; 
Bennet  &  Bennet,  2004),  trust  is  required  to  transform  our  current  information-hoarding 
culture  to  an  information-sharing  culture.  Our  current  information-hoarding  culture  is 
built  on  mistrust  at  all  levels.  The  use  of  program  office  portals,  ubiquitous  connectiv¬ 
ity,  and  collaboration  tools  is  only  effective  if  the  underlying  work  culture  is  ready  to 
accept  this  change. 

Net-centricity  embraces  communities  of  interest  (COIs)  in  large  part  because  it  has 
been  shown  that  transformation  in  the  work  culture  takes  place  within  and  through 
communities  (Lotze,  2004).  Communities  are  comprised  of  a  group  of  people  who 
work  towards  a  common  purpose.  Notions  of  collaboration  and  knowledge  sharing  are 
central  to  the  notion  of  community  in  the  knowledge  management  literature.  The  current 
version  of  the  draft  net-centric  environment  functional  concept  defines  a  net-centric 
environment  as: 
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A  framework  for  full  human  and  technical  connectivity  that  allows 
all  DoD  users  and  mission  partners  to  share  the  information  they 
need,  when  they  need  it,  in  a  form  they  can  understand  and  act  on 
with  confidence;  and  protects  information  from  those  who  should 
not  have  it.  (Net-Centric  FCB,  2004) 

While  this  discusses  sharing  the  information  needed,  communities  are  also  formed 
when  we  generate  a  shared  awareness  of  the  current  situation,  an  understanding  of 
the  cross-cutting  problems,  and  the  mechanism  for  sharing  innovations  across 
the  workforce. 


BEST  PRACTICES  WITHIN  COMMUNITIES 


The  Government  Accountability  Office  (GAO)  recently  stated  that  the  DoD’s 
acquisition  process  is  not  doing  a  good  job  of  incorporating  best  practices  and  lessons 
learned  (GAO,  2004).  While  a  response  might  be  yet  another  best  practices  clearing¬ 
house,  one  thing  the  literature  makes  clear — best  practices  are  largely  determined  and 
communicated  through  community  use  (Megill,  2004;  Wenger  et  al.,  2002).  While 
there  are  often  committees  to  designate  something  as  a  best  practice,  there  is  a  tacit 
process  of  innovation  that  occurs  long  before  a  practice  rises  to  be  designated  as  a 
best  practice  (Von  Krogh,  et  al,  2000). 


FIGURE  1.  BEST  PRACTICES  DETERMINED  THROUGH 
COMMUNITY  USE 
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The  development  of  functional  communities  that  span  both  government  and  industry, 
such  as  those  that  are  represented  in  the  Acquisition  Community  Connection  (ACC) 
portal  (http://acc.dau.mil),  serves  to  create  shared  government  and  industry  knowl¬ 
edge  repositories.  This  allows  the  collection  and  sharing  of  new  ideas  and  practices 
in  a  way  that  leverages  pockets  of  expertise  across  the  workforce.  New  ideas  that  are 
experimented  with  in  one  location  are  able  to  become  common  practice  through 
community  interaction  (Von  Krogh  et  al,  2000).  Over  time,  certain  practices  become 
preferred  among  community  practitioners.  It  is  only  after  many  preferred  practices 
are  identified  that  some  are  deemed  best  practices.  For  example,  many  in  the  risk 
management  community  find  a  preferred  practice  to  be  a  simple,  qualitative  approach 
matrix  for  assessing  risk.  If  the  majority  of  the  participants  identifying  and  assessing 
risk  are  only  novice  risk  practitioners,  this  approach  makes  sense.  However,  risk  experts 
generally  agree  that  a  best  practice  must  involve  a  statistical  analysis  during  the  risk 
assessment  process  (Driessnack  &  Dickover,  2003). 


Over  time,  <ertain  practices  betome  preferred 
among  tommunity  practitioners. 


More  important,  communities  allow  a  significant  transformation  in  how  learning  and 
training  are  conducted.  In  a  net-centric  investment  environment,  it  is  not  just  the  pro¬ 
gram  data  that  should  be  instantly  accessible;  the  information  and  tools  required  to 
perform  a  task,  solve  a  problem,  or  learn  a  skill  should  also  be  instantly  accessible  at 
the  time  of  need.  Communities  can  contextually  combine  policy,  guidance  information, 
performance  support  tools,  and  user-centered  learning  assets  with  community-devel¬ 
oped  knowledge  assets  such  as:  new  ideas;  common,  preferred,  and  best  practices;  case 
studies;  and  lessons  learned.  Discussions  among  novices,  practitioners,  and  experts  can 
be  integrated  into  a  structure  that,  over  time,  becomes  a  robust  knowledge  resource  that 
aids  in  learning  and  performance.  This  approach  enables  a  transformation  in  learning 
in  which  the  knowledge  worker  can  focus  on  learning  only  what  is  needed  to  perform 
effectively. 


DEFINING  COMMUNITY: 

DIFFERENCES  BETWEEN  COPS  AND  COIS 

In  the  DoD,  the  terms  Communities  of  Practice  (CoPs)  and  Communities  of  Interest 
(COIs)  are  both  employed.  Unfortunately,  there  is  some  confusion  about  where  one  term 
ends  and  the  other  begins.  The  distinction  between  these  terms  has  become  muddled  be¬ 
cause  of  the  differences  in  the  usage  in  the  knowledge  management  literature  versus  the 
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usage  in  the  DoD  net-centric  literature.  Within  the  knowledge  management  literature,  CoPs 
are  defined  by  the  American  Productivity  and  Quality  Consortium  as: 

Networks  of  people  who  come  together  to  share  and  learn  from  one 
another  face  to  face  and  virtually.  They  are  held  together  by  a  com¬ 
mon  interest  in  a  body  of  knowledge  and  are  driven  by  a  desire  and 
need  to  share  problems,  experiences,  insights,  templates,  tools,  and 
best  practices.  (APQC,  2000) 

Wenger,  McDermott,  and  Snyder  echo  this  sentiment  of  sharing  among  people 
when  defining  CoPs  as: 

Groups  of  people  who  share  a  concern,  a  set  of  problems,  or  a  passion 
about  a  topic,  and  who  deepen  their  knowledge  and  expertise  in  this 
area  by  interacting  on  an  ongoing  basis.  (Wenger  et  al.,  2002) 

Wenger,  McDermott,  and  Snyder  go  on  to  differentiate  a  CoP  from  a  COl  in  that  the 
CoP  is  about  something,  whereas  the  COl  is  just  seen  as  an  informal  network  of  people. 
In  their  eyes,  it  is  the  furthering  of  the  practice  within  a  knowledge  domain  that  gives 
the  CoP  its  uniqueness.  In  this  view,  which  is  prevalent  in  the  knowledge  management 
literature,  CoPs  are  seen  as  more  formal,  whereas  COIs  are  described  as  typically  more 
informal  in  nature. 

The  knowledge  management  literature  view  of  CoPs  as  formal  entities  and  COIs  as 
informal  entities  is  almost  diametrically  opposed  from  the  DoD  net-centric  literature, 
which  defines  the  COl  as  the  central  organizing  function  that  enables  collaboration  to 
work  in  a  data-centric  sense.  For  instance,  the  net-centric  DoD  frequently  asked  question 
(FAQ)  defines  a  COl  as: 

A  term  used  to  describe  any  collaborative  group  of  users  who  must 
exchange  information  in  pursuit  of  their  shared  goals,  interests, 
missions,  or  business  processes,  and  who  therefore  must  have  shared 
vocabulary  for  the  information  they  exchange.  The  COl  concept  is 
very  broad,  and  covers  an  enormous  number  of  potential  groups  of 
every  kind  and  size.  Any  element  of  a  DoD  component,  e.g.,  domain, 
organization,  task  force,  project  team  or  group  who  must  exchange 
information  may  be  considered  a  “COl.”  (DoD  CIO,  2004) 

Furthering  this  thought,  the  newly  released  DoDD  8320.2,  Data  Sharing  in  a  Net- 
Centric  Department  of  Defense,  states  that: 

Semantic  and  structural  agreements  for  data  sharing  shall  be  pro¬ 
moted  through  communities  (e.g.,  communities  of  interest  (COIs)), 
consisting  of  data  users  (producers  and  consumers)  and  system 
developers....  (DoDD  8320.2,  2004) 

In  a  DoD  net-centric  view,  COIs  become  the  primary  method  for  developing  shared 
vocabularies  for  data  exchange.  COIs  are  also  an  essential  step  in  building  the  shared 
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situation  awareness  that  enables  self-synchronization  of  the  warfighers.  This  operational 
stance  for  COIs  is  echoed  in  the  DoD  components.  For  instance,  the  Air  Force  Informa¬ 
tion  and  Data  Management  Strategy  (IMDS)  Policy  directs  Air  Force  data  producers,  the 
Major  Commands  and  Functional  Community  leaders,  to  execute  IMDS  responsibilities 
by  coordination  through  AF  COIs  (Department  of  the  Air  Force,  2004).  COI  tasks  become 
very  detailed  and  specific,  including  the  development  of  metadata  tags  and  portal- sharing 
specifications.  In  the  net-centric  literature,  many  COIs  are  formalized  through  chartered 
relationships  with  functional  control  boards  or  business  domains,  whereas  CoPs  are  rarely, 
if  ever,  discussed. 

This  is  problematic  in  that  the  contradictory  stances  between  the  knowledge  management 
literature  usage  and  the  DoD  net-centric  usage  has  negatively  impacted  both  understanding 
and  implementation  of  COIs  and  CoPs  in  the  DoD  environment.  The  average  workforce 
participant  is  often  confused  when  exploration  of  the  two  terms  yields  different  meanings. 
When  combining  these  contradictory  viewpoints,  COIs  become  completely  informal,  yet 
also  responsible  for  coming  up  with  concrete  metadata  standards  for  system  data  exchange. 
This  leads  to  misunderstandings  of  exactly  what  a  COI  is,  how  it  functions,  and  how  it 
would  be  supported.  COIs  that  are  tied  to  FCBs  are  envisioned  in  group  grope  meetings 
more  as  large  integrated  product  teams  (IPTs),  while  ad-hoc  COIs  become  something 
extremely  nebulous  that  other  people  out  on  the  Global  Information  Grid  (GIG)  will 
magically  figure  out  how  to  enact. 


Rarely  are  CoPs  mentioned  in  polity,  so 
they  become  something  for  people  to  do 
only  if  they  have  spare  time . 


If  COIs  are  confusing,  the  place  of  CoPs  in  the  net-centric  environment  is  even  worse. 
Rarely  are  CoPs  mentioned  in  policy,  so  they  become  something  for  people  to  do  only  if  they 
have  spare  time.  This  is  problematic,  as  CoPs  are  seen  as  the  primary  knowledge  manage¬ 
ment  and  sharing  vehicle  across  the  workforce.  In  one  contrasting  example,  a  DoD  manage¬ 
ment  initiative  directs  the  development  of  an  IT  Community  of  Practice  (DEPSECDEF, 
2004).  But,  because  CoPs  are  not  in  the  policy,  their  place  in  the  workforce  has  been 
marginalized.  In  practice,  this  makes  the  success  of  CoPs  an  uphill  struggle  for  the  CoP 
support  team. 

COMMUNITY  CATEGORIZATION:  WHICH  MODEL  DO  WE  USE? 

The  other  problem  in  understanding  what  to  do  with  communities  involves  the  incredibly 
broad  definition  given  for  communities.  If  communities  are  defined  as  virtually  any  encounter 
between  more  than  two  people  sharing  information,  there  is  very  little  guidance  that  can  be 
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provided,  either  in  modes  of  operation  or  in  community  support  requirements.  This,  in  es¬ 
sence,  goes  back  to  Kenneth  Boulding’s  famous  discussion  of  building  categories  for  different 
systems  types  in  general  systems  theory.  He  stated: 

A  general  theory  does  not  seek  to  establish  a  single,  self-contained 
general  theory  of  practically  everything  which  will  replace  all  the 
special  theories  of  particular  disciplines.  Such  a  theory  would  be 
almost  without  content,  and  all  we  can  say  about  practically  every¬ 
thing  is  almost  nothing.  Somewhere  between  the  specific  that  has  no 
meaning  and  the  general  that  has  no  content  there  must  be,  for  each 
purpose  and  at  each  level  of  abstraction,  an  optimum  degree  of 
generality.  (Boulding,  1956) 

To  paraphrase,  in  defining  communities  as  broadly  as  they  have  been,  all  we  can  say 
about  practically  all  communities  is  almost  nothing.  For  this  reason,  there  have  been  a  number 
of  attempts  to  provide  a  lower  level  of  specificity  required  to  make  communities  actionable 
through  the  development  of  different  category  structures  used  for  grouping  communities.  In 
attempting  to  capture  the  diversity  into  a  coherent  model,  everyone  takes  a  different  approach 
based  on  individual  needs  and  understanding  of  the  dynamics  involved.  It  is  hoped  that  we 
can  find  a  structure  that  can  represent  both  the  warfighter  and  investment  communities.  This 
is  important  because  in  a  net-centric  investment  environment,  the  interaction  amongst  the 
warfighter,  requirements  personnel,  and  acquisition  program  will  be  tighter  than  ever  (IT  RIT 
Pilot  Report,  2004). 


In  attempting  to  <apture  the  diversity  into  a 
toherent  model,  everyone  takes  a  different 
approath  based  on  individual  needs  and 
understanding  of  the  dynamks  involved. 


In  the  knowledge  management  literature,  Wenger,  McDermott,  and  Snyder  (2002)  describe 
the  variants  of  CoPs  on  a  number  of  different  scales  including: 

■  size  (small  or  big). 

■  length  of  the  life  span  (long-lived  or  short-lived). 

■  location  (collocated  or  distributed). 
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■  composition  (homogeneous  or  heterogeneous). 

■  organizational  boundaries  (within  a  business  unit,  across  business  units,  across  multiple 
organizations). 

■  level  of  planning  (spontaneous  or  intentional). 

■  level  of  recognition  (unrecognized  or  institutional). 

Within  DoD,  a  number  of  these  factors  are  not  relevant.  Most  of  the  communities  en¬ 
visioned  are  substantially  larger  than  most  of  the  CoP  literature,  which  usually  focuses  on 
communities  of  50  or  fewer.  In  the  acquisition  world,  communities  can  potentially  be  made 
up  of  thousands  of  government  and  industry  participants.  Additionally,  most  DoD  commu¬ 
nities  are  distributed,  so  co-location  is  not  as  critical  a  variable.  However,  the  rest  of  the 
characteristics,  including  life  span,  composition,  organizational  boundaries,  level  of  plan¬ 
ning,  and  recognition  all  impact  the  potential  nature  of  DoD  communities. 

In  2001,  the  DoD  Acquisition  Knowledge  Management  Working  Group  defined  com¬ 
munities  along  a  taxonomy  of  Product,  Executive,  Initiative- Specific,  and  Functional  com¬ 
munities  (Sylvester,  2001).  The  Artificial  Knowledge  Management  System  (AKMS)  model 
(see  Figure  2)  was  based  in  part  on  the  types  of  communities  that  were  envisioned  at  the 
time.  Product  communities  were  seen  only  as  programs  and  their  stakeholders.  The  execu¬ 
tive  communities  were  geared  more  toward  policy  change  activities,  such  as  the  DoD  5000 
updates.  Functional  communities,  while  often  logistics-related  at  that  time,  were  eventually 
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FIGURE  2.  AKMS  COMMUNITIES  OF  PRACTICE  TAXONOMY 
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FIGURE  3. 

NET-CENTRIC  FAQ  COMMUNITIES  OF  INTEREST  CHARACTERISTICS 


going  to  be  based  around  the  functional  career  fields.  The  initiative-specific  communities 
were  geared  around  hot  initiatives,  such  as  the  Reduction  of  Total  Ownership  Cost  (RTOC), 
that  involved  a  number  of  functional  areas. 

The  DoD  net-centric  FAQ  list  defines  COIs  on  a  scale  of  expediency  versus  institutional, 
and  functional  versus  cross-functional  characteristics  (DoD  CIO,  2004).  The  net-centric  FAQ, 
in  describing  this  break-out,  makes  clear  that  the  rationale  for  these  distinctions  concerns 
the  sharing  of  data  assets: 

Expedient  COIs  typically  exploit  existing  resources  (data  assets) 
produced  and  exposed  to  the  enterprise  for  discovery  and  reuse.  These 
resources  include  vocabulary,  developed  applications,  and  other  data 
assets... Institutional  COIs  tend  to  conduct  activities  such  as  develop 
vocabularies  to  provide  a  common  understanding  of  terms  used  within 
the  community,  develop  logical  data  models,  register  community 
specific  extensions  to  discovery  metadata  schemas,  and  identify  other 
data-related  capabilities  and  services....  Cross-Functional  is  the  idea 
of  Functional  Areas,  for  instance,  Heath  Affairs,  Personnel  &  Readi¬ 
ness  and  Environmental  working  together  to  address  data  issues  or 
topics  that  cross  the  boundaries  of  a  single  Functional  Area. 

While  the  sharing  of  data  assets  is  critical  for  building  the  GIG,  delegating  this  respon¬ 
sibility  to  COI  as  its  primary  function  has  some  negative  side  effects.  Collaboration,  as  a 
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NET-CENTRIC  FUNCTIONAL  CAPABILITIES  OPERATIONAL  SPACE 


term,  has  as  many  different  definitions  as  community  does.  In  transforming  the  COI  to  a 
data  sharing  input  vehicle,  we  have  in  essence  divorced  the  term  community  from  its  central 
role  in  the  knowledge  management  literature,  which  centers  on  knowledge  sharing  among 
people. 

This  really  brings  us  to  a  long-standing  debate  that  took  place  when  discussing  the  integrated 
digital  environment  (Megill,  2004).  Then  with  the  integrated  digital  environment,  and 
now  with  the  net-centric  environment,  the  question  still  remains  whether  we  see  the  core 
of  collaboration  as  primarily  involving  the  exchange  of  data  between  different  infor¬ 
mation  systems  via  discovery  services,  or  do  we  see  collaboration  as  a  function  that 
primarily  centers  around  people.  If  it  centers  on  the  connection  of  information  systems, 
then  discovery  services  and  metadata  standards  become  critical.  If  we  see  it  as  involving 
people,  we  tend  to  spend  more  time  discussing  trust  and  work  culture  transformation. 

In  reality,  both  the  automatic  connections  and  the  person-to-person  information  sharing 
are  essential  for  different  reasons.  In  a  real-time  war  environment,  there  is  clearly  a  need 
to  rapidly  download  information  essential  for  engaging  the  enemy.  But  also  critical  are  the 
ongoing  business  processes  that  relate  to  creating  periodic  information  products.  If  a  person 
is  responsible  for  creating  a  monthly  intelligence  assessment,  while  he  or  she  might  be  able 
to  discover  key  information  from  another  agency  to  include  in  this  month’s  report,  the 
availability  of  that  information  for  the  next  month’s  report  cannot  be  relied  on.  This 
type  of  process-centric  collaboration  occurs  only  if  the  two  agencies  develop  a  knowledge¬ 
sharing  relationship  (through  an  ad  hoc  COI,  for  instance)  in  which  each  agency  under¬ 
stands  the  new  interconnections  between  the  information  products  and  eventually  even 
develops  the  information  products  with  that  interconnection  in  mind. 
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The  Net-Centric  Joint  Functional  Concept  taxonomy  of  COIs  has  a  simpler,  more  straight¬ 
forward  breakout,  with  communities  listed  along  two  axis  points:  life  span  and  whether  the 
communities  are  formal  or  informal  in  nature  (see  Figure  4).  However,  in  the  net-centric 
investment  world,  the  Permanent/Informal  box  presents  us  with  a  dilemma  in  that  it  con¬ 
tains  only  standing  COIs.  Standing  COIs  in  this  model  would  include  both  those  tied  to 
FCBs  and  domains  and  functionally  based  CoPs.  The  primary  function  of  the  standing 
COIs  is  to  work  out  metadata  tagging  schemes,  while  the  functional  CoPs  are  a  knowledge¬ 
sharing  and  knowledge  repository  vehicle.  Each  community  type  would  require  different 
modes  of  interaction  and  would  have  different  support  concerns. 

Even  with  this  ambiguity,  in  looking  at  the  available  models,  this  model  provides  the 
easiest  delineation  for  integrating  the  different  communities  from  both  the  operational  world 
and  investment  world  into  one  chart.  In  looking  at  the  net-centric  investment  environment, 
we  find  that  there  are  a  number  of  different  communities  that  can  be  identified: 

■  Program  office  and  its  stakeholders:  This  is  essentially  looking  at  the  program  as  a 
community.  In  practice,  it  functions  through  a  formalized  IPT  structure. 

■  Standing  COI  tied  to  a  domain  or  FCB:  The  standing  COIs  are  responsible  for  working 
out  the  sharing  of  data  assets. 

■  Functionally  based  COIs  (CoPs):  The  CoPs  are  responsible  for  managing  the  knowledge 
associated  with  the  particular  knowledge  domain.  Additionally,  the  CoPs  become  a  vehicle 
for  on-the-job  learning  and  performance  support. 
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■  Product-oriented  working  groups:  Product-oriented  working  groups  are  tasked  with  fi¬ 
nalization  of  a  product,  such  as  an  update  to  the  5000  series. 

■  Ad  hoc  communities:  Ad  hoc  communities  are  the  catch-all  category,  in  that  groups  of 
people  can  come  together  for  a  myriad  of  reasons,  including  operational,  functional,  or 
exploratory. 

With  slight  modifications,  we  can  use  the  net-centric  FCB  approach  to  encapsulate  all 
communities  in  both  the  operational  world  and  in  the  net-centric  investment  environment. 
In  this  approach,  the  CoP  becomes  a  type  of  COI  that  is  focused  on  a  knowledge  domain 
and  is  interested  in  furthering  the  state  of  practice.  In  breaking  them  out  in  this  way,  we  can 
differentiate  the  support  approach  required  for  Standing  COIs  versus  Functional  COIs  (CoPs). 

Most  of  the  community  types  already  have  detailed  approaches  for  growth  and  sustain¬ 
ment.  The  traditional  organizations  (even  if  we  now  call  them  communities)  already  have 
common  methods  of  operation.  Working  groups  will  differ  in  size,  scope,  and  approach,  but 
these  too  already  have  clear  methods  of  operation.  The  Standing  COIs,  while  new,  have  had 
significant  work  devoted  to  determining  method  of  operations,  products,  and  overall  inte¬ 
gration  with  the  FCBs,  so  there  is  no  reason  to  outline  them  here.  However,  two  areas  that 
need  elaboration  are  the  functional  COIs  and  the  ad  hoc  COIs.  The  functional  COIs  (CoPs) 
need  elaboration  because  of  their  relatively  large  size  in  DoD  when  compared  to  the  bulk 
of  the  CoP  literature.  The  ad  hoc  COIs,  while  good  in  concept,  have  not  had  their  support 
concepts  fleshed  out  in  any  level  of  specificity. 


FOSTERING  AND  SUPPORTING  AD  HOC 
COMMUNITIES  OF  INTEREST 

Ad  hoc  COIs,  as  an  idea,  have  engendered  a  lot  of  enthusiasm,  yet  there  has  been 
relatively  little  specificity  provided  in  the  net-centric  documentation.  The  idea  is  that  to 
effectively  meet  new  and  previously  unforeseen  challenges,  ad  hoc  COIs  would  allow  the 
workforce  to  rapidly  respond  and  self-organize  to  address  the  challenges.  Through  discovery 
services,  the  information  products  on  the  GIG  will  have  metadata  that  will  allow  the  infor¬ 
mation  consumer  to  identify  and  decide  whether  the  information  product  is  useful.  In  some 
cases,  an  information  consumer  might  decide  to  form  a  COI  with  other  workforce  partici¬ 
pants.  The  question  still  being  discussed  is  how  to  transfer  the  ideas  for  ad  hoc  COIs  into 
an  operational  approach  for  implementation.  For  instance,  how  does  an  ad  hoc  COI  form? 
How  would  the  people  forming  an  ad  hoc  COI  figure  out  whom  to  invite  and  why  would 
they  want  to  come?  How  would  organizations  work  out  the  resourcing  issues  involved  in 
having  their  people  working  on  items  outside  their  mission  area? 

The  answer  lies  in  applying  tools  from  social  network  analysis  to  the  GIG  architecture. 
Social  network  analysis  involves  understanding  the  unofficial  social  networks  that  allow  one 
to  gain  access  to  necessary  information  and  to  collaborate  with  colleagues  to  actually  get 
things  done  (Cross,  2004).  The  COI  is  formed  when  someone  or  some  group  decides  there 
is  value  in  establishing  a  community.  For  an  ad  hoc  COI  to  form,  there  must  be  automated 
social  software  tools  in  place  that  provide  members  of  the  workforce  with  the  shared 
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situational  awareness  necessary  to  provide  the  person-to-person  connection-type  informa¬ 
tion  they  need  to  decide  if  there  is  expertise  available  that  can  help  them.  Ideally,  the  net- 
centric  environment  should  be  able  to  identify  and  make  discoverable  natural  clusters  of 
users  who  should  or  could  be  collaborating.  Users  may  be  clustered  based  on  the  type  of 
information  products  they  produce,  the  information  they  access,  or  the  initiatives  they  work. 
The  necessary  element  is  for  the  information  products  or  knowledge  assets  in  a  net-centric 
environment  to  have  contextual  information  tied  to  them  in  the  form  of  who  is  accessingit 
and  for  what  purpose. 

To  enable  ad  hoc  COIs  to  become  a  normal  part  of  our  daily  work,  at  least  three  key 
parts  need  to  be  in  place: 

1.  A  Method  to  Identify  Potential  COI  Members. 

2.  A  Method  to  Request  Participation. 

3.  A  Method  for  Organizations  to  Share  Resources. 
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A  METHOD  TO  IDENTIFY  POTENTIAL  COI  MEMBERS 


For  ad  hoc  COIs  to  work,  there  needs  to  be  a  method  for  people  to  find  each  other. 
The  reasons  for  establishing  a  COI  will  be  as  varied  as  the  time  frame  for  COI 
existence.  There  may  be  a  number  of  reasons  for  wanting  to  include  a  person,  role, 
or  organization,  including  the  knowledge  artifacts  people  have  published,  the  respon¬ 
sibility  of  their  job  role,  the  types  of  queries  they  have  been  running  or  the  initiatives 
they  are  working  on,  or  the  organization’s  mission. 

The  COI  initiator  or  requestor  needs  to  have  a  method  for  easily  locating  these  people 
in  the  course  of  the  normal  work  process.  One  way  to  do  this  is  to  employ  social  software 
or  social  network  analysis  tools  tied  to  information  product  access  and  use.  In  this  model, 
all  the  footprints  for  knowledge  access  are  captured  and  shared  as  security  access  permits. 
This  means  when  people  access  a  knowledge  asset,  they  should  be  able  to  see: 

■  The  knowledge  asset/information  product  creator. 

■  How  often  it  has  been  accessed. 

■  The  people  who  have  accessed  this  asset. 

■  The  projects  and  initiatives  that  have  accessed  this  asset. 

■  Formal  relationships  with  other  knowledge  assets. 

■  Other  knowledge  assets  accessed  by  these  same  people. 

■  Customized  taxonomies,  ontologies,  or  key  user  lists  that  this  asset  belongs  to  or 
is  linked  to  or  contained  within. 

■  Discussions  related  to  the  knowledge  asset. 

This  level  of  visibility  is  critical  to  the  creation  of  ad  hoc  COIs.  In  effect,  this  allows  our 
knowledge  assets  on  the  GIG  to  become  the  driver  in  developing  the  key  information¬ 
sharing  relationships  that  are  the  precursor  to  a  collaborative,  sharing  workforce. 


A  METHOD  TO  REQUEST  PARTICIPATION 

Once  the  COI  initiator  has  a  sense  of  who  should  be  interested  in  participating  in  an  ad 
hoc  COI,  there  needs  to  be  a  standardized  method  of  sending  a  request  for  participation. 
If  this  is  not  standardized  and  agreed  upon,  existing  organizational  barriers  will  serve  to 
minimize  any  significant  ad  hoc  collaboration.  The  request  must  include  a  clear  rationale 
for  both  the  COI’s  existence  along  with  why  the  requested  person  should  participate.  Most 
important,  the  rationale  should  include  a  priority  rating  (critical,  major,  minor),  anticipated 
time  frame  (immediate,  short  term,  long  term,  or  undetermined),  and  anticipated  level  of 
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effort  requested.  The  rationale  should  include  an  automated  report  of  the  social  network 
analysis  footprint  that  originally  prompted  the  initiator  to  request  participation. 


A  METHOD  FOR  ORGANIZATIONS  TO  SHARE  RESOURCES 

In  addition  to  a  request  for  participation,  there  needs  to  be  an  agreed-upon 
mechanism  for  sharing  resources  across  projects  and  organizations.  This  might  involve 
each  organization  maintaining  a  resource  pool  of  hours  for  ad  hoc  COI  participation 
against  which  an  organization  can  charge.  This  approach  would  allow  DoD  leader¬ 
ship  to  actually  assign  a  cost  and  level  of  effort  for  the  amount  of  knowledge  sharing 
they  are  expecting  to  occur.  Most  important,  industry  participants  should  be  included 
in  this  approach  as  they  may  have  key  expertise  that  could  make  the  difference, 
especially  in  a  critical,  high-priority,  time-sensitive  situation. 


SUPPORTING  LARGE-SCALE  COMMUNITIES  OF  PRACTICE 

In  the  DoD  acquisition  and  investment  world  our  functional  COIs  are  potentially  vast. 
With  approximately  100,000  government  workers  and  1  million  contractors,  the  potential 
number  of  participants  for  each  functional  community  could  easily  reach  into  the  thousands. 
This  creates  a  different  dynamic  from  what  we  find  in  the  knowledge  management  litera¬ 
ture.  The  knowledge  management  literature  tends  to  look  at  small-size  communities  in  which 
the  dynamic  involves  a  large  up-front  effort,  followed  by  an  ever-smaller  support  require¬ 
ment  as  the  community  stabilizes  (Wenger  et  al.,  2002).  Small  communities  follow  this 
trend  because  once  everyone  in  the  community  understands  the  norms  and  methods  of 
interaction,  less  support  is  required  to  keep  them  going.  But  in  large-scale  communities,  as 
the  level  of  success  increases,  the  number  of  new  members  increases.  This  leads  to  an 
increasing  need  for  overall  caring  and  support  until  a  steady  state  is  reached. 

To  effectively  manage  large-scale  communities,  a  number  of  support  structures  need  to 
be  in  place.  Most  important  is  the  idea  that  large-scale  communities,  if  they  are  to  be  ef¬ 
fective,  require  a  support  staff  to  provide  nurturing  and  growth,  along  with  supporting  various 
community  knowledge  management  functions.  Additionally,  a  number  of  capabilities  should 
be  present  in  laige-scale  communities,  including: 

■  Member  tracking  and  relationship  system:  The  member  tracking  system  is  neces¬ 
sary  for  guiding  community  interaction  efforts. 

■  Methods  to  determine  community  needs:  Within  each  community,  it  is  necessary 
to  determine  the  community  member’s  needs.  These  may  run  the  gamut  from  basic 
information  to  detailed  discussions  of  problems  to  rigorous  needs  assessments. 

■  Methods  to  determine  how  to  structure  and  integrate  the  content:  The  content  in 
the  community  section  should  be  structured  for  optimum  performance  support  and 
community  collaboration. 
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■  Requirements  fulfillment  team:  There  are  a  number  of  requirements  that  arise  in 
the  building  of  communities.  A  requirements  fulfillment  team  is  key  to  making 
these  a  reality.  This  team  will  have  a  number  of  skill  sets  geared  towards  fulfillment 
of  the  requirements.  Many  options  exist  for  meeting  the  requirements,  including: 

-  Custom  development  of  application  and  support  structures. 

-  Purchase  of  single  commercial  olf-the-shelf  (COTS)  software  solution  for 
requirements  fulfillment. 

-  Value-added-resale  of  COTS  software  that  is  enhanced  with  additional  fea¬ 
tures. 

-  Combination  of  COTS  software  with  additional  customization. 

-  Development  of  an  ensemble  of  COTS  software  products  to  meet  requirements 
needs. 

■  Content  Management  System:  Through  both  well-thought-out,  agreed-upon 
processes  and  automated  tools,  the  support  team  can  manage  the  site -wide  content 
over  time.  It  is  important  that  the  content  management  system  be  robust  enough 
while  not  becoming  overly  burdensome.  If  it  becomes  too  difficult  for  the 
community  members  to  make  contributions  and  act  on  the  content,  there  will  be 
no  interaction. 

■  Robust  Search  Capability:  The  community  site  needs  a  robust  search  capability  to 
allow  both  active  participants,  and  external  users  to  be  able  to  find  useful  content 
quickly.  Most  important,  content  needs  to  be  searchable  via  common  Internet  search 
engines. 

■  Community  Interaction  Measures:  Community  interaction  refers  to  the  level  of 
participation  within  a  community  of  practice.  Community  interaction  is  the  measure 
of  the  health  of  a  community.  This  is  the  engine  that  leads  to  more  valuable  knowl¬ 
edge  contributions,  more  subject  matter  expert  participation,  more  learning  oppor¬ 
tunities,  and  more  overall  value  for  the  community.  Community  interaction  can 
occur  online  or  offline.  Community  interaction  measures  can  be  both  qualitative 
and  quantitative  and  should  drive  the  overall  community  development  process 
actions. 


CONCLUSION 

This  article  provides  guidance  on  applying  communities  within  a  net-centric  in¬ 
vestment  environment.  Unfortunately,  the  current  usage  of  COI  in  net-centric  envi¬ 
ronment  literature  is  significantly  different  from  its  usage  in  knowledge  management 
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literature  and  is  further  confused  by  the  absence  of  CoPs  from  net-centric  literature. 
After  gaining  a  clearer  understanding  of  the  different  usages,  COIs  and  CoPs  are  two 
complimentary  terms  that  can  co-exist.  The  key  to  this  merging  involves  expanding 
the  net-centric  notion  of  COIs  from  being  primarily  a  mechanism  to  develop  data 
exchange  standards  for  consumption  by  discovery  services  to  being  a  vehicle  for 
collaboration  among  people,  which  holds  just  as  much  priority  as  functioning  as  a 
data  exchange  service  between  information  systems. 
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